Corridor Selection and Fine Tuning for the Corridor Method

In this paper we present a novel hybrid algorithm, in which ideas from the genetic algorithm and the GRASP metaheuristic are cooperatively used and intertwined to dynamically adjust a key parameter of the corridor method, i.e., the corridor width, during the search process. In addition, a fine-tuning technique for the corridor method is then presented. The response surface methodology is employed in order to determine a good set of parameter values given a specific problem input size. The effectiveness of both the algorithm and the validation of the fine tuning technique are illustrated on a specific problem selected from the domain of container terminal logistics, known as the blocks relocation problem, where one wants to retrieve a set of blocks from a bay in a specified order, while minimizing the overall number of movements and relocations. Computational results on 160 benchmark instances attest the quality of the algorithm and validate the fine tuning process. 1 The Corridor Method: An Introduction The Corridor Method (CM) has been presented by [1] as a hybrid metaheuristic, linking together mathematical programming techniques with heuristic schemes. As illustrated in [2], the basic idea of the CM relies on the use of an exact method over restricted portions of the solution space of a given problem. Given an optimization problem P , the basic ingredients of the method are a very large feasible space X , and an exact method M that could easily solve problem P if the feasible space were not too large. Since, in order to be of interest, problem P is assumed to be hard, the direct application of M to solve P usually becomes unpractical when dealing with real world as well as large scale instances. The CM defines method-based neighborhoods, in which a neighborhood is build taking into account the method M used to explore it. Given a current feasible solution x ∈ X , the CM builds a neighborhood of x, say N (x), which can effectively be explored by employing M . Ideally, N (x) should be exponentially large and built in such a way that it could be explored in (pseudo) polynomial time using M . In this sense the CM closely relates to very large scale neighborhood search as well as the so-called dynasearch; see, e.g., [3, 4]. Typically, the corridor around an incumbent solution is defined by imposing exogenous constraints on the original problem. The effect of such constraints is to identify a limited portion of the search space. The selection of which portions of the search space should be discarded can be driven by a number of factors, in primis, as the power of the method itself deployed to explore the resulting neighborhood. However, one could also envision the design of a stochastic mechanism that, after dividing the search space in portions, or limited regions, selects which of these subspaces should be included in the current corridor. Factors such as, e.g., a greedy score, the cardinality of each subregion, etc., could be used to bias the stochastic selection mechanism that drives the definition of the corridor around the incumbent solution. The stochastic mechanism could be designed such that, on the one hand, the corridor selection is non-deterministic, so that at every step different corridors around the same incumbent solution could be created and, on the other hand, such selection is still influenced by a merit score, accounting for the attractiveness of each portion of the search space. Following such cooperative greedy stochastic corridor construction process, a balance between diversification and intensification is achieved, since, even though more promising regions of the search space have higher probabilities of being selected, not necessarily the best subregions will always be chosen. In the next sections we will illustrate how this cooperative idea can be employed to design an effective algorithm for a well-known problem arising, e.g., at container ports. First, we illustrate the problem; then the algorithm is described, and subsequently numerical results are presented. More details about the problem as well as the steps of the algorithm are provided in [2]. 2 The Blocks Relocation Problem Relocation is one of the most important factors contributing to the productivity of operations at storage yards or warehouses [5]. A common practice aimed at effectively using limited storage space is to stack blocks along the vertical direction, whether they be maritime containers, pallets, boxes, or steel plates [6]. Given a heap of blocks, relocation occurs every time a block in a lower tier must be retrieved before blocks placed above it. Since blocks in a stack can only be retrieved following a LIFO (Last In First Out) discipline, in order to retrieve the low-tier block, relocation of all blocks on top of it will be necessary. Let us consider a bay with m stacks and n blocks. In line with the available literature [6, 7], we introduce the following assumptions: A1: pickup precedences among blocks are known in advance. We indicate the pickup precedence with a number, where blocks with lower numbers have a higher precedence than blocks with higher numbers; A2: when retrieving a target block, we are allowed to relocate only blocks found above the target block in the same stack using a LIFO policy; A3: relocation is allowed only to other stacks within the same bay; A4: relocated blocks can be put only on top of other stacks, i.e., no rearrangement of blocks within a stack is allowed. In the literature, the problem of arranging containers to maximize efficiency is extensively discussed; see, e.g., [8] for a recent survey on quantitative approaches to container terminal logistics. One approach to the problem is the retrieval problem considering relocations called blocks relocation problem (BRP). If the current configuration of the bay is taken as fixed, one might be interested in finding a sequence of moves to be executed, while retrieving blocks according to a given sequence, in order to minimize the overall number of relocation moves. While in the shuffling problems containers are rearranged but not removed, in this version of the problem, at each step, a container is removed from the bay, hence reducing the number of containers in the bay until all containers have been picked up from the bay. Exact as well as approximate algorithms have been proposed to minimize the number of relocations while retrieving blocks (see, e.g., [9–12, 6, 7]). In this paper, we present an enhanced algorithm for the BRP. The algorithm is made up of (i) a corridor definition phase, during which exogenous constraints are imposed to construct a corridor around the incumbent solution; (ii) a neighborhood design and exploration phase, where the corridor is used to define the boundaries of the neighborhood to be explored; (iii) a move evaluation and selection phase, where a greedy rule is used to evaluate the fitness of the solutions in the neighborhood and to select a restricted pool of elite solutions and, finally, (iv) a trajectory fathoming phase, in which a logical test is employed to determine whether the current trajectory can be pruned without loosing any improving solution. The major contribution of the paper is two-fold: on the one hand, we propose an effective way of enhancing the performance of a CM based algorithm by hybridizing such algorithm with ideas from genetic algorithms (GA) and GRASP; on the other hand, it is the first time that a statistically sound attempt to fine tune a CM inspired algorithm is carried out, hence contributing to the realm of metaheuristic calibration and fine tuning. Let us first describe how the CM can be applied to the BRP. The basic idea of the CM is related to the imposition of exogenous constraints upon the original problem, such that the search space is reduced. Given an incumbent bay configuration T , the goal of the BRP is to retrieve the block with highest priority in the bay. However, due to the LIFO policy assumption, whenever such target block is not in the uppermost tier of a stack, i.e., whenever other blocks are currently placed upon the target block, relocation operations will first be required in order to finally retrieve the target block. Given the uppermost block currently located in the same stack of the target, a decision regarding where to relocate such block must be made. Obviously, such decision affects the future retrieval process, since the relocated block might be placed on top of other blocks and, therefore, it might imply the need of further relocations in the next steps. The size of the search space describing all the possible relocations of a set of blocks grows exponentially with respect to the number of blocks moved at each step. A simple way to limit the size of the search space describing the possible configuration that can be reached starting from the initial bay configuration is to impose “constraints,” or limitations, upon the use of stacks. Let us suppose we are given a bay with m stacks. This implies that, when a relocation of a block l is required to retrieve a target block k, block l can be placed on top of any stack different from the one where it is currently located, i.e., m − 1 possible relocations arise. In turn, all of these m−1 possible scenarios give raise to m−1 new configurations, with an exponential growth in the number of configurations. However, let us assume that, whenever a relocation of a block is required in order to retrieve a target block, we are allowed to move such block on only δ < m of the available m−1 stacks, hence creating δ different configurations. Figuratively, we could say that such exogenous constraint builds a horizontal corridor around the incumbent configuration, determining which configurations can be reached starting from the incumbent one. The value of parameter δ can be used to control the width of the corridor and, therefore, the growth of the search space. In a similar fashion, a second parameter λ can be used to introduce a bound on the maximum height of a stack, i.e., a vertical corridor. Consequently, a stack can be used to relocate blocks only if the maximum height has not yet been reached. 3 The Cooperative Algorithm Given an incumbent bay configuration, let us indicate with Ti the ordered list of blocks in stack i, with i = 1, . . . ,m, where the first and the last elements of the list represent the blocks at the top and at the bottom of the stack, respectively. Consequently, we represent the incumbent bay configuration T as a sequence of stacks, i.e., T =< T1, . . . , Tm >. Given an incumbent bay configuration T , with a total of N blocks, let us indicate with k ∈ [1, N ] the target block, i.e., the block with highest priority in T . Index t, with t ∈ [1,m], is used to indicate the stack in which block k is found. In addition, let us indicate with L the list of blocks above the target block in stack t, and with l the uppermost block in list L, i.e., the current block to be relocated. Let us now define the concept of forced relocations. Given a current bay configuration, as in Figure 1, the number of forced relocations is given by the number of blocks in each stack currently on top of a block with higher priority. Such blocks will necessarily be relocated, in order to retrieve the block with higher priority located below. For example, in Figure 1, the number of forced relocations is equal to 4, as indicated by the shaded blocks. It is worth noting that the number of forced relocations in a bay constitutes a valid lower bound of the minimum number of relocations required to complete the retrieval operation. The proposed algorithm terminates when only the block with the lowest priority is left in the bay and is made up of four phases: Corridor definition: Given the incumbent configuration and the current block to be relocated, a corridor around the incumbent solution is defined. The corridor width is influenced by the value of parameter δ, which indicates the number of stacks available for relocation. As illustrated above, in order to